Protected device management

ABSTRACT

A method, apparatus, system, and computer program product for management of storage devices protected by encryption, user authentication, and password protection and auditing schemes in virtualized and non-virtualized environments.

COPYRIGHT NOTICE

Contained herein is material that is subject to copyright protection.The copyright owner has no objection to the facsimile reproduction ofthe patent disclosure by any person as it appears in the Patent andTrademark Office patent files or records, but otherwise reserves allrights to the copyright whatsoever.

TECHNICAL FIELD

The present disclosure relates generally to management of devicesprotected by encryption, user authentication, and password protectionschemes.

BACKGROUND

Corporate data are increasingly mobile, distributed, and prolific. Dataare routinely taken out of physically secured facilities to accommodateworkers who travel or have flexible working habits. Data are alsodistributed geographically as corporations' business interests take theminto other cities, states, and countries. Data are prolific in both therate at which they are generated and in the multi-media formats in whichthey can be presented. All of these forces drive the evolution of newstorage media, higher bandwidth subsystems, and network-connectedstorage that require that data be protected both while in transit andwhile at rest.

Data-at-rest (DAR) encryption technology prevents the unauthorized useof data stored on lost or stolen storage devices, thereby preventingthese data from being spread on the Internet or other networks. DARencryption acts as an automated and quick response mechanism to preventthe inevitable loss and theft of storage devices from becoming the lossand theft of the data stored on those devices.

One of the challenges of protecting data stored on various storagedevices associated with a computing platform is that encryptiontechnologies and key management strategies differ depending upon theentity performing the encryption. Storage hardware may have built-inencryption capabilities that are unique to the storage hardware vendor,thereby requiring use of the storage hardware vendor's tools to accessthe data. Software-based encryption requires different key generationand management services than hardware-based encryption and may thereforerequire use of the software vendor's tools to access thesoftware-encrypted data. Planning for key recovery and migration of datain the event of theft or loss may therefore require use of a number ofdifferent vendors' tools to protect and/or recover all of the dataassociated with a computing platform.

Another challenge of protecting data stored on storage devices is thatthe storage devices themselves may be protected using a passwordprotection scheme. For example, in accordance with the AdvancedTechnology Attachment (ATA) specification, a disk lock is a built-insecurity feature of a hard disk drive. The ATA specification requiresthat a disk has two passwords: a User password and a Master password. Adisk can be locked in two modes: High security mode or Maximum securitymode. In High security mode, the disk can be unlocked with either theUser or Master password, using the “SECURITY UNLOCK DEVICE” ATA command.There is an attempt limit, normally set to 5, after which the disk mustbe power cycled or hard-reset before unlocking can be attempted again.Also in High security mode the SECURITY ERASE UNIT command can be usedwith either the User or Master password.

In Maximum security mode, the disk cannot be unlocked without the Userpassword. The only way to get the disk back to a usable state is toissue the SECURITY ERASE PREPARE command, immediately followed by theSECURITY ERASE UNIT command. In Maximum security mode the SECURITY ERASEUNIT command requires the User password and will completely erase alldata on the disk. Thus, if the disk is password protected, set toMaximum security mode, and the User password is unknown, data on thedisk is not recoverable.

Yet another challenge of protecting data stored on storage devicesassociated with a computing platform is that the platform may requireauthentication of user credentials before access to data on theassociated storage devices is allowed. For example, some computingplatforms are protected using Kerberos user authentication. Kerberosuses as its basis the symmetric Needham-Schroeder protocol. It makes useof a trusted third party, termed a key distribution center (KDC), whichconsists of two logically separate parts: an Authentication Server (AS)and a Ticket Granting Server (TGS). Kerberos works on the basis of“tickets” which serve to prove the identity of users.

The KDC maintains a database of secret keys; each entity on thenetwork—whether a client or a server—shares a secret key known only toitself and to the KDC. Knowledge of this key serves to prove an entity'sidentity. For communication between two entities, the KDC generates asession key which they can use to secure their interactions. Thesecurity of the protocol relies heavily on participants maintainingloosely synchronized time and on short-lived assertions of authenticitycalled Kerberos tickets.

Under the Kerberos protocol, a client authenticates itself to theAuthentication Server and receives a ticket. (All tickets are timestamped.) The client then contacts the Ticket Granting Server, and usingthe ticket it demonstrates its identity and asks for a service. If theclient is eligible for the service, then the Ticket Granting Serversends another ticket to the client. The client then contacts the ServiceServer, and using this ticket it proves that it has been approved toreceive the service.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system configured to manage devicesprotected by encryption, user identity authentication, and passwordprotection schemes in accordance with one embodiment of the invention.

FIG. 2 shows further details of the system of FIG. 1 in managingprotected devices in accordance with one embodiment of the invention.

FIG. 3 is a flowchart of a method to be performed upon reset of a systemhaving devices protected by encryption, user identity authentication,and password protection schemes in accordance with one embodiment of theinvention.

FIG. 4 is a flowchart of a method to be performed upon receiving acommand to unlock devices protected by encryption, user identityauthentication, and password protection schemes in accordance with oneembodiment of the invention.

FIG. 5A shows further details of the system of FIG. 1 in enablingdevices protected by encryption, user identity authentication, andpassword protection schemes to be dynamically attached and the userauthentication credentials to be dynamically reconfirmed withoutrebooting in accordance with one embodiment of the invention.

FIG. 5B is a flow diagram of a method to be performed by the system ofFIG. 5A upon recognizing a hot plug event of a device.

FIG. 6 shows further details of the system of FIG. 1 in managingprotected devices in accordance with one embodiment of the invention.

FIG. 7 is a flowchart of a method to be performed upon detecting apotentially-auditable event occurring within a secure partition of asystem in accordance with one embodiment of the invention.

FIG. 8 shows a virtual machine environment for implementing a securepartition for managing actions such as protecting devices usingencryption, user identity authentication, and password protectionschemes in accordance with one embodiment of the invention.

DETAILED DESCRIPTION

Embodiments of the present invention may provide a method, apparatus,system, and computer program product for managing systems having devicesprotected by encryption, user identity authentication, and passwordprotection schemes.

Reference in the specification to “one embodiment” or “an embodiment” ofthe present invention means that a particular feature, structure orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the invention. Thus, the appearances ofthe phrases “in one embodiment,” “according to one embodiment” or thelike appearing in various places throughout the specification are notnecessarily all referring to the same embodiment.

For purposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the presentinvention. However, it will be apparent to one of ordinary skill in theart that embodiments of the present invention may be practiced withoutthe specific details presented herein. Furthermore, well-known featuresmay be omitted or simplified in order not to obscure the presentinvention. Various examples may be given throughout this description.These are merely descriptions of specific embodiments of the invention.The scope of the invention is not limited to the examples given.

In one embodiment, protected device management is provided within asecure partition that provides an isolated and controlled environment.The secure partition may receive commands to perform managementoperations from a trusted management application. The secure partitionensures that commands to manage protected devices are verified asoriginating with an authenticated source. The trusted managementapplication may be remote from the system and may communicate via asecure communication channel with the secure partition.

The isolated and secure environment of the protected device manager maycomprise a variety of different types of partitions, including anentirely separate hardware partition (e.g., utilizing Intel®Corporation's Manageability Engine (“ME”), Active ManagementTechnologies (“AMT”), Platform Resource Layer (“PRL”) and/or othercomparable or similar technologies) and/or a virtualized partition(e.g., a virtual machine in Intel® Corporation's VirtualizationTechnology (“VT”) scheme). It will be apparent to those of ordinaryskill in the art that a virtualized host may also be used to implementME, AMT and PRL technologies (as described in further detail below withreference to FIG. 8.)

In one embodiment, a protected device manager executes in a securepartition that is isolated from a host operating system of the system.The secure partition may receive a request to unlock an encrypted devicecoupled to the system. The request is received by the secure partitionvia a secure communication channel established between a trusted remoteconsole and the secure partition. The secure partition unlocks theencrypted device in response to the request without involvement of thehost operating system.

The secure partition may receive a token from the trusted remote consoleand use the token to unwrap a key used to encrypt blocks of theencrypted device. The secure partition may obtain the key from a securestorage area of the encrypted device, wherein the secure storage area ishidden from the host operating system. The secure partition may confirmthat the request originated with the trusted remote console prior tounlocking the encrypted device. The secure partition may perform amanagement operation after the encrypted device is unlocked, wherein therequest further specifies the management operation to be performed, andboot the host operating system after the management operation isperformed. Unlocking the encrypted device may be performed when the hostoperating system of the system is malfunctioning and without involvementof a user of the system.

FIG. 1 illustrates a system configured to manage devices protected byencryption, user identity authentication, and password protectionschemes in accordance with one embodiment of the invention. Platform 100includes a processor 110 connected to a chipset/secure partition 120 viaa desktop management interface (DMI) 111 a. Chipset/secure partition 120includes a manageability engine (ME) 130, which may be implemented as amicroprocessor, to manage the configuration and operation of platform100. In one embodiment, manageability engine (ME) 130 collects auditevents, authenticates users, controls access to peripheral devices,manages encryption keys for protection of data stored on storage devicesof platform 100, and interfaces with management console 166 via networkcontroller 160. Using management console 166, manageability engine (ME)130 maintains consistency with enterprise-wide policies forconfiguration and management of platforms such as platform 100.Manageability engine (ME) 130 is connected to processor 110 via hostembedded controller interface (HECI) 111 b.

Virtualization engine controller interface (VECI) 111 c connectsprocessor 110 to I/O command decode module 140 of chipset/securepartition 120. In one embodiment, I/O command decode module 140 is ageneral-purpose controller that is configured using specialized firmwareto perform storage command decoding and other accelerated operations.The functionality of I/O command decode module 140 may also beimplemented entirely in special-purpose hardware. I/O command decodemodule 140 provides management functionality to protect data written tostorage devices associated with platform 100. For example, I/O commanddecode module 140 may interact with encryption engine 150 to encryptstorage devices, protect metadata used for protecting storage devices,intercept and process hardware interrupts related to storage devices,and facilitate management operations on storage devices.

Manageability engine (ME) 130 controls the behavior of I/O commanddecode module 140 and encryption engine 150 by configuring policies andencryption keys. The operation of manageability engine (ME) 130, I/Ocommand decode module 140, and encryption engine 150 is described infurther detail below.

Platform 100 further includes memory devices such as dynamic randomaccess memory (DRAM) 114, static random access memory (SRAM) 122 withinchipset/secure partition 120, and flash memory 190. When platform 100 isfully powered, a portion of DRAM 114 referred to as an upper memory area(UMA), ME-UMA 116, is available for use by manageability engine (ME)130. The host operating system 115 for platform 100 is not able toaccess ME-UMA 116, in general, because of a memory isolation mechanismthat is configured by the Basic Input Output System (BIOS). This memoryisolation mechanism locks access to ME-UMA memory 116 before the hostoperating system runs. By isolating this portion of DRAM 114 for use bymanageability engine 130 from the host operating system, the integrityof manageability engine 130 is protected from viruses or other malwarethat might infect host operating system 115.

Flash memory 190 contains firmware used to initialize platform 100. Thisinitialization firmware includes BIOS firmware 192, network controllerfirmware 194 to configure network controller 160, and chipset firmware196 to configure chipset/secure partition 120. The integrity of thechipset firmware 196 for manageability engine (ME) 130 and I/O commanddecode module 140 is ensured by means of a digital signature before itis stored on the flash memory 190. Data for use by manageability engine(ME) 130, such as user authentication information, may be encrypted byencryption firmware within manageability engine (ME) 130 and stored in adata region 198 of flash memory 190.

The embodiment of platform 100 shown in FIG. 1 further includesUniversal Serial Bus (USB) controller 175 connected to USB device 177.USB devices may include pointing devices (such as mice), keyboards,digital cameras, printers, personal media players, flash drives, andexternal hard drives. The USB specification enables installation andremoval of devices without opening the computer case (hotswapping) orrestarting the computer, making it useful for mobile peripherals,including drives of various kinds. Originally conceived and still usedtoday for optical storage devices (CD-RW drives, DVD drives, etc.),several manufacturers offer external portable USB hard drives, or emptyenclosures for disk drives, which offer performance comparable tointernal drives, limited by the current number and type of attached USBdevices and by the upper limit of the USB interface (in practice about40 MiB/s for USB 2.0 and perhaps potentially 400 MiB/s or more for USB3.0). These external drives have typically included a “translatingdevice” that bridges between a drive's interface (IDE, ATA, SATA, PATA,ATAPI, or even SCSI) to a USB interface port. Functionally, the driveappears to the user much like an internal drive. Other competingstandards for external drive connectivity include eSATA, ExpressCard(now at version 2.0), and FireWire (IEEE 1394).

The embodiment of platform 100 shown in FIG. 1 further includesdifferent types of storage devices accessible via an I/O controller 170,including a non-volatile memory storage device 172 accessible viastorage interface 171 and Serial Advanced Technology Attachment (SATA)storage device 180 accessible via storage interface 181. Storageinterface 171 may be implemented as a non-volatile memory (NVM) hostcontroller interfaces (HCI) for non-volatile memory and storageinterface 181 may be implemented as an Advanced HCI (AHCI) interface forSerial Advanced Technology Attachment (SATA) storage device 180. I/Ocontroller 170 includes both NVM and SATA controller functionality.

Data stored on storage devices 172 and 180 may be encrypted byencryption engine 150 of chipset/secure partition 120. SATA storagedevice 180 is used as an example of a chipset-encrypted device, andfurther includes a reserved area for storing metadata 182, whichincludes at least one device encryption key (DEK) 184 for storage device180 and other metadata used by manageability engine (ME) 130. Metadata182 is protected from being overwritten by applications running onprocessor 110 during processing of I/O commands by I/O command decodemodule 140 and I/O controller 170.

In one embodiment, before encryption or decryption of data is performedby the encryption engine 150 of chipset/secure partition 120,manageability engine (ME) 130 inserts a Device Encryption Key (DEK),such as DEK 184, associated with a storage device involved in aninput/output operation into a memory register associated with encryptionengine 150. If one physical storage device is logically divided into anumber of different logical devices or partitions, then each logicaldevice or partition may have its own respective Device Encryption Key(DEK), and each of those DEKs may be inserted into a respective memoryregister for encryption engine 150.

In one embodiment, manageability engine (ME) 130 manages encryption ofall data associated with platform 100, including encryption performed byencryption engine 150 within chipset/secure partition 120, as well asencryption of data that is not performed by the chipset but instead thatis performed by software running on processor 110 or by storage hardwareitself. One of the services provided by manageability engine (ME) 130 ismanagement of encryption keys in a common framework and user interface,regardless of the component of the platform 100 that is performing theencryption of the data. Further details about the framework andoperation of chipset/secure partition 120 and manageability engine (ME)130 in managing encryption of data is provided in patent applicationSer. No. 12/319,210, entitled “Enforcing Use of Chipset Key ManagementServices for Encrypted Storage Devices,” naming as inventor Ned Smith,which is hereby incorporated by reference herein in its entirety.

FIG. 2 shows further details of the manageability engine (ME) 130 andI/O command decode module 140 components of chipset/secure partition 120of FIG. 1 in accordance with one embodiment of the present invention.Within chipset/secure partition 120, manageability engine (ME) 130includes an ME kernel 231, ME common services 233, protected devicemanager 235, security/key management firmware 237, and identitymanagement firmware 239. Each of these components is discussed infurther detail below.

ME kernel 231 provides basic functionality, including memory usage ofSRAM 122 and portions of DRAM 112 (such as ME-UMA 114), storage of datapersistently in flash memory 190, and access control. ME kernel 231controls the operation of I/O command decode module 140 and encryptionengine 150.

ME common services 233 include services commonly needed by differentfirmware modules, and include security services, networking services,and provisioning services. Security services provided by ME commonservices 233 generally include user authentication consisting of bothHTTP Digest and Kerberos authentication; domain authorization usingMicrosoft Active Directory and/or other services; clock synchronizationservices to synchronize client and server clocks; and security auditingservices.

Networking services provided by ME common services 233 comprise aTransmission Transport Protocol/Internet Protocol (TCP/IP) stack,Transport Layer Security (TLS), Hypertext Transport Protocol (HTTP),Simple Object Access Protocol (SOAP), Web Services for Manageability(WS-MAN), and a host-based TLS interface called the Local ManageabilityService (LMS).

Provisioning services provided by ME common services 233 are used inconjunction with management console 166 of FIG. 1 to provisionenterprise software to platform 100. These provisioning services supporttwo deployment modes: zero touch and one touch. With zero touch mode,deployment certificate anchor keys are stored in a data storage areasuch as data region 198 of flash memory 190 of FIG. 1, allowingwell-known certificate authority keys to be used to validate ITcredentials that can then be used to take ownership of the platform. Onetouch mode configures organizational certificates, symmetric keys, andtrusted hosts that may be used to complete setup and deployment tasksremotely.

Manageability engine 130 also includes out-of-band (OOB) communicationmodule 230. OOB communication module 230 facilitates communicationbetween components of platform 100 with corresponding components ofmanagement console 166 via network controller 160. OOB communicationmodule 230 establishes a secure OOB communication channel 168 betweenchipset/secure partition 120 and management console 166.

Manageability engine (ME) 130 also includes identity management firmware239. Identity management firmware 239 may compare the user'sauthentication information with user account metadata stored, forexample, in data region 198 of flash memory 190. Identity managementfirmware 239 may also interact with security/key management firmware 237of the manageability engine (ME) 130 to confirm that the user'sinformation is also stored in a container within a storage device suchas SATA storage device 180. This confirmation of the user's access to aparticular storage device such as SATA storage device 180 provides anadditional layer of protection of data stored on SATA storage device180.

Security/key management firmware 237 manages keys such as encryptionkeys created by encryption engine 150. Security/key management firmware237 may also authenticate users before access to data stored on storagedevices associated with platform 100 is allowed. Security/key managementfirmware 237 manages key management information and stores this keymanagement information in a memory or storage device associated with theplatform, such as flash memory 190 or SATA storage device 180. Thelocation in which key management information is stored depends upon thestorage space available and amount of data to be stored, and theinvention is not limited to a particular configuration for storing keymanagement information. In one embodiment, security/key managementfirmware 237 encrypts the key management information using a platformcontainer key (PCK), which is bound to platform 100.

Key management information managed by security/key management firmware237 includes encryption keys generated by the chipset (i.e., byencryption engine 150 within chipset/secure partition 120) and stored inmetadata 182, referred to as a Device Encryption Key (DEK) 184.

Manageability engine (ME) 130 is further shown as including protecteddevice manager 235. In one embodiment, protected device manager 235communicates with I/O command decode module 140 to supply a devicepassword used to unlock a device such as SATA storage device 180. Theoperation of protected device manager 235 is described in further detailbelow with reference to FIGS. 3 and 4.

I/O command decode module 140 is shown as including I/O module kernel241 and SATA virtualization firmware 243. I/O module kernel 241 providesbasic functionality to I/O command decode module 140 and receivescommands from ME kernel 231. While SATA virtualization firmware 243 isdescribed with reference to this embodiment as firmware, thefunctionality of SATA virtualization firmware 243 may also beimplemented as dedicated hardware. SATA virtualization firmware 243 isused to access SATA storage devices such as SATA storage device 180 andenables manageability engine (ME) 130 to perform device managementfunctions. For example, SATA virtualization firmware 243 enables remoteaccess of protected devices by management console 166 by injecting SATAcontrol packets into the I/O data stream without involvement of the hostoperating system 115 or of other host software running on processor 110.Control packets may be used, for example, to unlock SATA storage device180 via commands from management console 166.

SATA virtualization firmware 243 is also used to hide a range of linearblock addresses on SATA storage device 180 from host operating system115. This range of hidden linear block addresses hidden from hostoperating system access is referred to herein as a secure storage areathat is protected so that the device metadata 182 can be stored on thedrive. Device metadata 182 may include a device encryption key 184 thatenables the encryption and decryption of blocks of SATA storage device180.

SATA virtualization firmware 243 may also intercept events detected byI/O controller 170, such as hot-plug interrupts generated when a newdevice is attached to platform 100. SATA virtualization firmware 243 mayalso monitor the I/O stream to and from storage devices and detectevents for auditing.

In one embodiment, SATA storage device 180 is protected using bothencryption and a password, such as an ATA password, that must be enteredby a user before the device can be accessed. The password is used tounlock a native locking mechanism of SATA storage device 180. Encryptionengine 150 is used to encrypt blocks of SATA storage device 180. TheSATA device encryption key (DEK), such as DEK 184, is stored on the SATAdevice in a location that is hidden to the host operating system. Thedevice is first unlocked using the password for the native lockingmechanism before the DEK can be accessed to decrypt the encryptedblocks.

When platform 100 is reset, I/O command decode module 140 andmanageability engine (ME) 130 cooperate to read device metadata, such asthe encryption keys and user authentication credentials, from the deviceand store the device metadata in secure storage, such as flash memory190 data region 198 as device metadata 298. In one embodiment, for eachuser that can be authenticated to the management console 166, there is atoken, such as Token-1 266A of FIG. 2, which is used to derive awrapping key for a particular device. The device wrapping key is in turnused to wrap that particular device's encryption key.

The user wrapping key and device wrapping key are used together todetermine whether a user can access a particular device, and the userwrapping key/device wrapping key pairs are stored in flash memory 190data region 198 as device metadata 298. In contrast, the deviceencryption key such as DEK 184 is stored on the storage device itself.When the device is to be accessed, a copy of the Token-1 is used todetermine the appropriate user wrapping key/device wrapping key pairfrom device metadata 298. The device wrapping key of the pair is used todecrypt metadata 182 on the device, which exposes the device encryptionkey 184. Token-1 is used to perform management operations on the storagedevice when no user is present or when the user cannot produce theneeded authentication credentials.

In one embodiment, device metadata 182 is encrypted by encryption engine150 using another device wrapping key derived by another token, referredto herein as Token-2, that is stored on a USB device such as USB device177. USB device 177 is intended to be securely stored at a physicallocation away from where a thief might have access. Token-2 is used toperform management operations on the storage device when no networkconnection is available for the remote management console 166 to connectto the storage device. The USB device 177 contains Token-2 in anunencrypted, clear-text form so that the holder of Token-2 is implicitlyauthorized to perform management operations on the storage device. IfToken-2 is provided, a second set of user wrapping keys is derived usingToken-2, and the second set of user wrapping key/device wrapping keypairs would also be stored in flash memory 190 as part of devicemetadata 298. Both the Token-1 and Token-2 values are guarded by a userauthentication system such as identity management firmware 239 so thatonly authorized users are able to expose the device encryption keys.

In one embodiment, Token-1 266A is securely archived in remote storage266 associated with management console 166 (or in a directory service),along with the device 180 password 266B. Device 180 password 266B andToken-1 266A are used by the management console 166 to remotely unlockthe SATA device 180. Device 180 password 266B is provided by remotemanagement console 166 to protected device manager 235, which uses thedevice 180 password 266B to unlock the device. Protected device manager235 provides Token-1 266A to security/key management firmware 237, whichmay make use of identity management firmware 239 to unwrap a userwrapping key. The user wrapping key is used to unwrap a device wrappingkey, which is used to decrypt metadata 182 and thereby provide access todevice encryption key 184 that can be used by encryption engine 150 todecrypt blocks of SATA storage device 180. Token-1 266A is protectedfrom network attacks by relying on a secure communication channel suchas OOB communication channel 168 between management console 166 and thechipset/secure partition 120. OOB communication channel 168 may besecured using, for example, Kerberos session keys.

Because data on SATA storage device 180 may be encrypted, the deviceencryption key (DEK) 184 is stored in a location accessible bymanageability engine (ME) 130 protected device manager 235. By makingthe DEK available to protected device manager 235, SATA read/writerequests via the HECI/VECI interfaces 111 b and 111 c can be servicedeven though the data on SATA storage device 180 are encrypted. Onceprotected device manager 235 has access to the password to unlock SATAstorage device 180, protected device manager 235 can make a copy of thedevice wrapping key which is stored in device metadata 298. The devicewrapping key can be used to unwrap the device encryption key containedin device metadata for each SATA device attached to the platform.

FIG. 3 is a flowchart of a method to be performed upon reset of a systemhaving devices protected by encryption, user identity authentication,and password protection schemes in accordance with one embodiment of theinvention. The method of FIG. 3 will be described as being performed bythe components of the system of FIG. 2, although the method is notlimited to such an implementation. Upon a system reset, control proceedsto “ME Protected Device Manager Reads Device Metadata from SATA DevicesIndirectly via I/O Command Decode Module Over MECI” step 310. In step310, manageability engine 130 protected device manager 235 obtainsinformation about attached storage devices by reading device metadatafrom SATA devices such as SATA storage device 180. Because manageabilityengine 130 is not directly connected to storage devices, manageabilityengine 130 protected device manager 235 accesses device metadataindirectly via I/O command decode module 140 over MECI 131.Manageability engine 130 protected device manager 235 uses SATAvirtualization firmware 243 to access the device metadata stored on SATAdevices such as SATA storage device 180. SATA virtualization firmware243 exposes a storage interface to protected device manager 235, so thatSATA storage device 180 appears as a block storage device of linearblock addresses. SATA virtualization firmware 243 hides some of thelinear block addresses from the host operating system and exposes themto protected device manager 235. SATA virtualization firmware 243interacts with SATA storage device 180 using the SATA I/O protocol.

From “ME Protected Device Manager Reads Device Metadata from SATADevices Indirectly via I/O Command Decode Module Over MECI” step 310,control proceeds to “I/O Command Decode Module Reads Virtual DriveDefinition Metadata Containing Metadata Descriptor Information” step320. In step 320, I/O command decode module 140 SATA virtualizationfirmware 243 reads virtual drive definition metadata that containsmetadata descriptor information that is stored in metadata 182 stored onSATA storage device 180. In one embodiment, SATA virtualization firmware243 virtualizes storage devices, so that multiple virtual drivepartitions can be recognized. Each of these virtual drive partitions isdescribed in the virtual drive definition data. Contained within thefirst virtual hard disk drive (HDD) definition may be traditional drivegeometry elements. For example, beginning at Linear Block Address (LBA)zero, a Master Boot Record (MBR) may be stored, followed by the drivedata, such as the operating system files and user files. Some systemshave hidden partitions that may be used by BIOS or other systemutilities. A Host Protected Area (HPA) may be used to store an emergencyrecovery OS (ROS), a multimedia utility, diagnostic utilities, or otherprograms. Systems that implement Redundant Arrays of Inexpensive Disks(RAID) may place RAID metadata at the end of the virtual drive. Byplacing RAID metadata at the end of the virtual drive, the RAID optionalROM can easily locate RAID metadata at system initialization.

In one embodiment, a single Device Encryption Key, such as DEK 184,spans each virtual HDD on the device, resulting in all virtual HDDsbeing encrypted with the same key. Virtual Drive Definition (VDD) datais placed at the end of the physical drive, such as at the last LinearBlock Address LBA-n. VDD data contain drive geometry, marking thebeginning and end of each virtual HDD. The VDD also identifies the startand end locations of the manageability engine metadata area, such as thestart and end locations of metadata 182. The VDD and ME metadata may notbe encrypted by encryption engine 150 but the contents of metadata 182are protected by I/O command decode module 140 and manageability engine(ME) 130.

In one embodiment, metadata 182 includes an AHCI file system block,pre-boot authentication (PBA) code, and PBA metadata. An AHCI filesystem is used by a firmware storage driver, which may be executed byprocessor 110. Metadata 182 may also include the wrapped DEK 184, deviceconfiguration data, drive conversion status information, and a drivemigration package that may be used to migrate the device, such as SATAstorage device 180, to another platform. The migration package alsocontains a copy of the DEK 184 wrapped with a recovery key that is notspecifically tied to a platform. Metadata 182 may also contain PBAexecutables and an identifier for a storage area containing PBA code tobe executed during pre-boot on the host processor 110 before the hostoperating system is loaded. For example, this storage area containingPBA code may be a portion of flash memory 190. Access to the PBA area ispermitted by code executing on host processor 110 via the I/O commanddecode module 140 using VECI 111 c or via manageability engine (ME) 130via a host command interface that uses HECI 111 b. I/O command decodemodule 140 ensures that requests to access the PBA storage area arelimited to the range of storage in which PBA executables are storedbecause PBA code executes on the host processor 110.

When I/O command decode module 140 SATA virtualization firmware 243reads virtual drive definition metadata that contains metadatadescriptor information that is stored in metadata 182 stored on SATAstorage device 180 in “I/O Command Decode Module Reads Virtual DriveDefinition Metadata Containing Metadata Descriptor Information” step320, the metadata descriptor information may include multiple instancesof a wrapped device encryption key such as DEK 184 within devicemetadata 182. For example, DEK 184 may be wrapped both by a devicewrapping key that is platform-specific as well as wrapped by a recoverykey that is not tied to platform 100. Because multiple instances of thedevice encryption key may be present, there is a need to determine thelocation of the particular device encryption key that can be unwrappedusing the user authentication credentials involved in performing thesystem reset.

As described above, the user performing the system reset will have anassociated user wrapping key that is used to wrap a device wrapping key.The user wrapping key/device wrapping keys are stored in device metadata289 of flash memory 190. Control proceeds to “I/O Command Decode ModuleLocates User Authentication Metadata Offset and Reads Device Metadata”step 330. In step 330, I/O command decode module 140 uses the metadatadescriptor information to locate a user authentication metadata offsetwithin flash memory 190 for the user credentials being used to performthe system reset. User authentication metadata and other device metadataare read from the location of flash memory 190 that is identified by theoffset.

After reading device metadata 298 from flash memory 190 in “I/O CommandDecode Module Locates User Authentication Metadata Offset and ReadsDevice Metadata” step 330, control proceeds to “ME Protected DeviceManager Stores Device Metadata in Secure Storage” step 340. For example,ME protected device manager 235 may store device metadata including userauthentication credentials for SATA storage device 180 in devicemetadata 298 of flash memory 190 for later access by manageabilityengine (ME) 130. Control then proceeds to “ME Protected Device ManagerWaits for a Manageability Operation Command to be Issued” step 350. Forexample, ME protected device manager 235 waits for a manageabilityoperation command, such as an unlock command, to access SATA storagedevice 180. When a manageability operation command is received, MEprotected device manager 235 can access the stored metadata to obtainuser authentication credentials and/or other information needed toaccess SATA storage device 180.

FIG. 4 is a flowchart of a method to be performed upon receiving acommand to unlock devices protected by encryption, user identityauthentication, and password protection schemes in accordance with oneembodiment of the invention. The method of FIG. 4 will be described asbeing performed by the components of the system of FIG. 2, although themethod is not limited to such an implementation. Two examples of methodflows are provided in FIG. 4, depending upon the origin of the requestto unlock a protected device. The method steps included in remote unlockblock 402 involve processing a remote unlock command, such as an unlockcommand received from management console 166 via a secure communicationchannel such as OOB communication channel 168. The method steps includedin USB unlock block 418 involve processing an unlock command inconjunction with a USB device storing a token to unlock the storagedevice.

The method steps in remote unlock block 402 for processing a remoteunlock command begin with “Management Console Triggers Remote UnlockRequest for a SATA Device” step 404. Management console 166 may initiatethe request in response to enterprise management policies, or managementconsole 166 may act in response to a notification from manageabilityengine (ME) 130 that a device such as SATA storage device 180 should beunlocked. Management console 166 triggers the request to unlock theencrypted SATA device via the manageability engine (ME) 130 andchipset/secure partition 120 in circumstances when no user is present atthe keyboard, when a user is present but unable to successfullyauthenticate to the platform, when the platform is in a low power state(such as one of the Advanced Configuration and Power Interface (ACPI) Sxpower states S1 through S5), when the system is connected via a wired orwireless network or outside a corporate firewall but the device isinaccessible, and when the host operating system for the system ismalfunctioning.

Control proceeds from “Management Console Triggers Remote Unlock Requestfor a SATA Device” step 404 to “Management Console Connects to SecurePartition; Sends Disk Unlock Command Containing Token-1 and DevicePassword” step 406. Management console 166 can use an independentlysecured and encrypted channel such as OOB communication channel 168 tosend secure commands that instruct unlock operations to an embeddedsecurity subsystem provided by chipset/secure partition 120. When thesecure communication channel such as OOB communication channel 168 isestablished between management console 166 and chipset/secure partition120, Kerberos authentication is used by identity management firmware 239to authenticate the management console 166 and manageability engine (ME)130. If the remote unlock request was initiated by the manageabilityengine (ME) 130, after establishing the secure communication channel,management console 166 can obtain user credentials such as a usernameand password for a user associated with platform 100. If the remoteunlock request was initiated by management console 166, administratoruser credentials may be used for platform 100. These user credentialsare used by management console 166 to obtain an associated password forthe device, such as device 180 password 266B, and token used to decryptthe device, such as Token-1 266A from management data store 266.

In “Management Console Connects to Secure Partition; Sends Disk UnlockCommand Containing Token-1 and Device Password” step 406, the devicepassword is included in the unlock command so that the device can beunlocked using the device password. By including Token-1 in the command,a user wrapping key/device wrapping key can be identified, such as indevice metadata 298. The user wrapping key/device wrapping key can beused to decrypt blocks of the encrypted storage device, includingmetadata 182 that includes the device encryption key 184.

From “Management Console Connects to Secure Partition; Sends Disk UnlockCommand Containing Token-1 and Device Password” step 406, controlproceeds to “ME Protected Device Manager Validates Command Originatedfrom Trusted Console” step 408. The Kerberos authentication credentialsthat were necessary to establish a secure communication channel betweenmanagement console 166 and chipset/secure partition 120 may be used tovalidate that the command originated with the trusted management console166. Control then proceeds to “ME Protected Device Manager Uses Token-1to Unwrap a Copy of the DEK in Device Metadata” step 410. As describedabove, once protected device manager 235 has access to the device 180password 266B to unlock SATA storage device 180, protected devicemanager 235 can make a copy of the device wrapping key which is storedin device metadata 298 of flash memory 190. The device wrapping key canbe used to unwrap the device encryption keys contained in devicemetadata for each SATA device attached to the platform.

Once ME protected device manager 235 obtains the device encryption keyfor the encrypted storage device, control proceeds to “ME Security/KeyManagement Firmware Writes DEK to Encryption Engine into KeyslotRegister Corresponding to the SATA Device” step 412. As described inpatent application Ser. No. 12/319,210, entitled “Enforcing Use ofChipset Key Management Services for Encrypted Storage Devices,” namingas inventor Ned Smith, which is incorporated herein by reference above,device encryption keys may be stored in keyslot registers withinencryption engine 150. When the device is accessed, encryption engine150 then uses the stored device encryption keys from the correspondingkeyslot register to decrypt data stored on the corresponding device.

After the device encryption key is made accessible to encryption engine150 in “ME Security/Key Management Firmware Writes DEK to EncryptionEngine into Keyslot Register Corresponding to the SATA Device” step 412,control proceeds to “ME Protected Device Manager Performs ManageabilityOperation (which may include Booting the OS)” step 414. For example, inresponse to a remote unlock command, ME protected device manager 235unlocks the device, which may including providing a device password tounlock the device and using encryption engine 150 to decrypt blocks ofthe encrypted device. If the device is further encrypted by hostsoftware, the manageability operation may require management console 166to communicate with trusted host software to further decrypt the device.In response to a USB unlock command, ME protected device manager 235similarly unlocks the device, including using a device password tounlock the device and encryption engine 150 to decrypt blocks of theencrypted device. Depending upon the particular manageability operationcommand being processed, the platform may be rebooted, including bootingthe host operating system.

After the manageability operation is performed in “ME Protected DeviceManager Performs Manageability Operation (which may include Booting theOS)” step 414, control proceeds to “ME Protected Device Manager Resetsthe Platform Resulting in the SATA Device becoming Locked Again” step416. ME protected device manager 235 performs the steps described withreference to FIG. 3 to reset the system, which results in the storagedevice being locked again.

As described above, FIG. 4 also includes method steps for unlocking adevice manually using a USB unlock command. The method steps in USBunlock block 418 for processing a USB unlock command begin with “BIOSApplication Prompts User to Insert USB Device Containing Token-2” step420. Upon system startup, a BIOS application prompts the user to inserta USB device containing Token-2 to enable the user to access a devicesuch as SATA storage device 180. For example, such a BIOS prompt mightbe provided if the user is unable to supply a password to access thedevice. Control proceeds to “BIOS Reads Token-2 and Sends it to MEProtected Device Manager via HECI/DHCI” step 422. The BIOS applicationreads Token-2 provided by the user and sends Token-2 to ME protecteddevice manager 235 via HECI 111 b. Control then proceeds to “MEProtected Device Manager Uses Token-2 to Unwrap a Copy of the DEK inDevice Metadata” step 424. As described above, once protected devicemanager 235 has access to an unlock token to unlock SATA storage device180, protected device manager 235 can make a copy of the Device Wrap Key(DWK) which is stored in device metadata such as flash memory 190 dataregion 198. The DWK can be used to decrypt the DEK contained in devicemetadata for each SATA device attached to the platform. After the deviceencryption key is made accessible to encryption engine 150 in “MESecurity/Key Management Firmware Writes DEK to Encryption Engine intoKeyslot Register Corresponding to the SATA Device” step 412, controlproceeds as described above.

The system of FIGS. 2, 3, and 4 enable a device to be unlocked withoutinvolvement of a host operating system. Special considerations arenecessary if it is desirable that the credentials of a user of a systembe authenticated before access is allowed to any device attached to thesystem. This authentication typically occurs upon booting the system, sothat devices that are dynamically attached without rebooting the systembypass the confirmation of the user's authentication credentials. It ispreferable that access to a hot-plugged device by a user beauthenticated, but rebooting the system to confirm the user'scredentials is unduly burdensome. Enabling authentication for dynamicattachment of a storage device is useful, for example, in ensuring thatdynamic replacement of storage devices that are part of a RAID array areperformed by an authorized user.

A similar problem occurs in a device that is locked or encrypted usingATA commands. An ATA-locked or ATA-encrypted device is unlocked by theBIOS at system startup, and thus cannot be hot-plugged into a system.Rebooting the system is necessary to unlock or decrypt the device beforedata on the device can be accessed.

The system of FIGS. 5A and 5B enables access to a hot-plugged device tobe conditioned upon authentication of the credentials of a user of thesystem. The hot-plugged device can be unlocked and/or decrypted and theuser's credentials can be confirmed without rebooting the system, evenif the device is locked or encrypted using ATA commands.

The system of FIGS. 5A and 5B requires authenticating first credentialsof a user of a system before access is allowed to any device of aplurality of devices attached to the system. An event indicatingattachment of a new device to the system is intercepted by a securepartition of the system that is isolated from a host operating system ofthe system. Second credentials to access the new device are requestedwithout booting the system, the second credentials are authenticated,and access to the new device is enabled after authenticating the secondcredentials. A hot plug event for the new device is delivered from thesecure partition to the host operating system.

Requesting the second credentials to access the new device may includeusing trusted path connections to a display device to display a requestfor the second credentials and a user input device to receive the secondcredentials. Authenticating the first and second credentials may includeauthenticating the first and second credentials with a trusted thirdparty. The second credentials may include a password for the new device,and enabling access to the new device may include using the password tounlock the new device. The second credentials may include a useridentifier, and enabling access to the new device may include providingthe user identifier to a trusted third party and enabling access to thenew device if the trusted third party authenticates the user identifier.

FIG. 5A shows further details of the system of FIG. 1 in enablingdevices protected by encryption, user identity authentication, andpassword protection schemes to be dynamically attached and the userauthentication credentials to be dynamically reconfirmed withoutrebooting in accordance with one embodiment of the invention.Manageability engine kernel 531, manageability engine common services533, security/key management firmware 537, I/O module kernel 541, andSATA virtualization firmware 543 operate as described with reference tocorresponding components of the system of FIG. 2.

Within manageability engine (ME) 130, identity management firmwareKerberos client 539A interacts with identity management firmwareKerberos server 539B to authenticate users. Kerberos client 539Aimplements the Kerberos protocol to a Key Distribution Center, such asKey Distribution Center 164 of FIG. 1. Kerberos client 539A may usetrusted I/O firmware 536 (if available) to use trusted path connectionsto a display device and a user input device to obtain credentials from auser of the system. Kerberos client 539A may provide the usercredentials to Key Distribution Center 164 and obtain a Kerberos ticketto access a Kerberos service, such as Kerberos server 539B. Kerberosserver 539B enables access to SATA storage device 180 upon receiving aKerberos ticket indicating that a user's credentials to access thedevice have been authenticated. The Kerberos ticket may include anextension field that contains a user token, such as Token-1 266A of FIG.2, that enables generation of a user wrapping key that can be used tounwrap a device wrapping key and a device encryption key as describedabove with reference to FIG. 2. The Kerberos ticket may also include anextension field that contains a device password, such as device 180password 266B of FIG. 2, that can be used to unlock the device.

Within I/O command decode module 140, hot plug virtualization firmware545 decodes hot plug events received by I/O controller 170 and processesthose events prior to forwarding a hot plug event to the host operatingsystem 115. The operation of hot plug virtualization firmware 545 isdescribed in further detail with reference to FIG. 5B.

FIG. 5B is a flow diagram of a method to be performed by the system ofFIG. 5A upon recognizing a hot plug event of a device. In action 5.1,I/O controller 170 detects a SATA hot plug event, where SATA storagedevice 180 has been dynamically attached to platform 100. In action 5.2,hot plug virtualization firmware 545 intercepts the hot plug event andinteracts with SATA virtualization firmware 543 to discover attributesof the device. Hot plug virtualization firmware 545 request access tothe hot-plugged device from Kerberos client 539A of identity managementfirmware 539. If the device is locked using an ATA password scheme, ATAencryption, and/or chipset-based encryption, hot plug virtualizationfirmware 545 may also notify Kerberos client 539A that SATA storagedevice 180 is locked as part of the request to access the device.

In action 5.4, Kerberos client 539A obtains user information such asuser authentication credentials. Kerberos client 539A may determinewhether the user's credentials are cached locally within manageabilityengine (ME) 130, such as in SRAM 122. If the user's credentials arecached locally, actions 5.4 and 5.5 may be bypassed. If the user'scredentials are not cached locally, these user authenticationcredentials may be obtained via trusted I/O firmware 536 if available onplatform 100. Trusted I/O firmware 536 makes use of trusted pathconnections, such as a trusted path connection to a display device todisplay a request for the credentials and a trusted path connection to auser input device, such as a keyboard, to receive the credentials. In anembodiment in which trusted I/O firmware 536 is not available onplatform 100, a notification may be sent to a host agent (not shown)running on processor 110 that a new device has been attached. The hostagent can gather the user's credentials and connect to thechipset/secure partition 120 to unlock the device and make the devicevisible to host operating system 115.

In action 5.5, Kerberos client 539A obtains a Kerberos ticket from keydistribution center 164. In one embodiment, the Kerberos ticket isprovided along with an unlock token for the user, such as Token-1 266Aof FIG. 2, for SATA storage device 180 and an ATA password belonging tothe user, such as device 180 password 266B of FIG. 2. This unlock tokenand ATA password for the user may be obtained from a directory service,such as management console 166 of FIGS. 1 and 2. The Kerberos ticketconfirms the authenticity of the user's credentials to receive servicefrom Kerberos server 539B. In one embodiment, Kerberos server 539Benables Kerberos client 539A to all access other services withinmanageability engine (ME) 130, such as services from security/keymanagement firmware 537 and protected device manager 539. In otherembodiments, a separate Kerberos ticket may be obtained to accessservices provided by other manageability engine (ME) 130 components,such as security/key management firmware 537. In one embodiment, theunlock token for the user for SATA storage device 180 and the ATApassword belonging to the user are delivered as an extension field thatis part of the Kerberos session key.

In action 5.6, Kerberos client 539A confirms the user's credentials withKerberos server 539B. In an alternative embodiment, Kerberos client 539Amay confirm the user's credentials directly with key distribution center164 without going through a local Kerberos server such as Kerberosserver 539B. For example, Kerberos client 539A may obtain a Kerberosticket to access a different user authentication service such as anActive Directory service that will return Token-1 266A and device 180password 266B in a subsequent exchange. In one embodiment, managementconsole 166 of FIGS. 1 and 2 may proxy a connection to a different userauthentication service and/or host the user authentication serviceitself.

Actions 5.7 through 5.10 describe actions taken if the hot-plugged SATAstorage device 180 is protected by a native locking mechanism such as anATA password or ATA encryption. If the device is not protected by anative locking mechanism such as ATA password or ATA encryption, steps5.7 through 5.10 would be bypassed.

In action 5.7, in a situation where hot-plugged SATA storage device 180has been locked using an ATA password, Kerberos client 539A provides theuser's ATA password to protected device manager 535. In action 5.8,protected device manager 535 provides the user's ATA password to SATAvirtualization firmware 543 of I/O command decode module 140. In action5.9, SATA virtualization firmware 543 sends an ATA command to I/Ocontroller 170 to unlock SATA storage device 180. In action 5.10, I/Ocontroller 170 uses the ATA command to unlock SATA storage device 180.As described above, if the SATA storage device 180 has been encrypted byencryption engine 150, security/key management firmware/Kerberos server537 may work in conjunction with identity management firmware/Kerberosclient 539 to use the user's unlock token contained in an extensionfield of the Kerberos ticket to derive a user wrapping key. The userwrapping key can be used to access a device wrapping key and deviceencryption key from SATA storage device 180.

Actions 5.11 and 5.12 describe actions taken if the hot-plugged SATAstorage device 180 is encrypted by encryption engine 150. If thehot-plugged SATA storage device is not encrypted by encryption engine150, steps 5.11 and 5.12 would be bypassed. If the hot-plugged SATAstorage device 180 is encrypted by chipset/secure partition 120encryption engine 150, in action 5.11, Kerberos client 539A may requestsecurity/key management firmware 537 to enable device decryption forhot-plugged SATA storage device 180. The user credentials may be used toobtain the device encryption key as described above with reference toFIG. 2. In action 5.12, the device encryption key 184 is provided toencryption engine 150. As described above, the device encryption key maybe written to a keyslot register of encryption engine 150 and used byencryption engine 150 to decrypt blocks of the hot-plugged device SATAstorage device 180. If the hot-plugged SATA storage device 180 is alsoprotected by an ATA password, the steps described above with referenceto actions 5.7 through 5.10 to unlock SATA storage device 180 are usedto unlock the device before the device encryption key stored on thedevice can be accessed.

In action 5.13, Kerberos client 539A notifies hot plug virtualizationfirmware 545 that access to SATA storage device 180 has been approved.As described with reference to actions 5.7 through 5.10, if SATA storagedevice 180 was locked with an ATA password, the device has beenunlocked. As described with reference to actions 5.11 and 5.12, if thedevice was encrypted by encryption engine 150, decryption has beenenabled. In action 5.14, hot plug virtualization firmware 545 delivers ahot plug event to host operating system 115. Host operating system 115then has access to the unlocked and decrypted data from SATA storagedevice 180. In response to receiving the host plug event, host operatingsystem 115 may invoke a file system to mount SATA storage device 180and/or incorporate SATA storage device 180 into a RAID array.

In the systems described above with reference to FIGS. 1 through 5B,encryption of storage devices is performed within chipset/securepartition 120 by encryption engine 150. Furthermore, the systemsdescribed with reference to FIGS. 1 through 5B above provide encryptionand protected device management functionality within a secure partitionof the system that is isolated from the host operating system. Forexample, encryption engine 150 resides within chipset/secure partition120, protected device manager 235 of FIG. 2 resides in manageabilityengine (ME) 130 within chipset/secure partition 120, and SATAvirtualization firmware 543 and hot plug virtualization firmware 545 ofFIG. 5B reside within I/O command decode module 140 of chipset/securepartition 120.

Typically, auditable events are captured in auditing software runningunder control of a host operating system and/or BIOS. Because themanagement and encryption functionality described herein is isolatedfrom the host operating system and BIOS, events performed within thesecure partition are not captured by typical auditing software. However,it is desirable to capture and audit events that affect the managementof protected devices and encryption of stored data. It is also desirableto perform audit operations in an environment that is protected frompotential corruption of the host operating system and/or BIOS. It isalso preferable to capture audit information at the time and within thesecure environment in which an auditable event occurs.

FIG. 6 shows further details of the system of FIG. 1 in managingprotected devices in accordance with one embodiment of the invention.Manageability engine kernel 631, manageability engine common services633, protected device manager 635, security/key management firmware 637,and identity management firmware 639 operate as described with respectto counterpart components of FIGS. 2 and 5A.

In the embodiment shown in FIG. 6, manageability engine (ME) 130includes a manageability engine audit subsystem 638 and I/O commanddecode module 140 includes an I/O module audit subsystem 648.Manageability engine audit subsystem 638 and I/O module audit subsystem648 identify and process auditable actions that occur within theirrespective components of chipset/secure partition 120. Because I/Ocommand decode module 140 prepares data for I/O to storage devices andworks directly with encryption engine 150 to encrypt data as the dataare written to storage devices, I/O module audit subsystem 648 capturesauditable events that occur during I/O. In contrast, manageabilityengine (ME) 130 is not directly involved with I/O to storage devices,and thus manageability engine audit subsystem 638 captures auditableevents related to management of protected devices. For example,manageability engine audit subsystem 638 captures events involvingconfiguration and setup of systems to manage encryption, userauthentication, device initialization and failure, encryption keys,theft detection, and other enterprise platform management policies.

Manageability engine audit subsystem 638 and I/O module audit subsystem648 communicate via manageability engine controller interface (ME) 131.Manageability engine audit subsystem 638 may also communicate with aremote audit administration service 640 within management console 166via OOB communication channel 168, network controller 160, andout-of-band communication module 630.

In one embodiment, auditable events are defined in an audit policy. Theaudit policy may define auditable events for which audit event recordsare to be generated as well as other non-auditable events that may beignored. Because auditing every event that occurs within a system couldgreatly degrade performance of the system, the audit policy is used toselectively capture events of specific interest in accordance withorganizational priorities and policies. In one embodiment, an audit bitmask is used as a selector to activate and deactivate different hardwareand/or firmware components that are capable of detecting auditableevents.

Types of events in an audit policy may include encryption systemprovisioning/deprovisioning events; user management events; devicemanagement events; key management events; device initialization events;theft detection events; and device failure events. Specific auditableevents may include events triggered by actions external to the securepartition of the system, such as events triggered by a host operatingsystem that cause activity within the secure partition, and/or actionsoccurring internally within the secure partition, such as interrupts.

Externally-triggered events may include enabling or disabling theftprotection services; creating, deleting, or modifying a user account;user logon/logoff success or failure; encryption key generated ordeleted, for various types of encryption keys such as device encryptionkeys, device wrap keys, and recovery keys; device configured forencryption or decryption; device conversion or de-conversion as asecurity-managed device; device configuration for PASS_THROUGH; devicemigration or preparation for device migration; device encryption key(DEK) insertion or removal from encryption engine registers; audit eventpolicy registration or deregistration; recovery of platform or devicemetadata; user of local platform token; changes in encryption policy,such as changes to key strength, key refresh, or remote configuration ofencryption policy; transitions between authenticated and unauthenticatedencryption; device unlock operations; device failure.Internally-triggered auditable events may include self-test failure ofthe manageability engine, I/O command decode module, encryption engine,and/or interfaces to the secure partition; Federal InformationProcessing Standard self-test success or failure; audit initializationfailure; and/or memory failure.

When an event is detected by manageability engine audit subsystem 638 orI/O module audit subsystem 648, a determination may be made whether thedetected event is one of the auditable events defined in the auditpolicy. If the detected event is one of the auditable events in theaudit policy, the event is identified as an auditable event.

The audit policy may include instructions for servicing audit eventrecords for each auditable event. The audit policy may further specifyactions to be taken if an auditable event cannot be logged. For example,manageability engine audit subsystem 638 or I/O module audit subsystem648 may be configured to halt or undo (reverse the effects of) anoperation for which an audit event record cannot be written to an auditlog. Furthermore, the audit policy may specify handling of exhaustedaudit storage log resources, so that manageability engine auditsubsystem 638 or I/O module audit subsystem 648 can be configured tooverwrite the audit log or to cease writing audit event records to theaudit log.

In one embodiment, each of manageability engine audit subsystem 638 andI/O module audit subsystem 648 generates an audit event record for anidentified auditable event. The audit event record is written to anaudit log that is isolated from the host operating system. In theembodiment shown in FIG. 6, manageability engine audit subsystem 638writes auditable events to audit log 610, and I/O module audit subsystemwrites auditable events to audit log 620. In one embodiment, audit log610 is stored in an isolated area of a flash memory such as an isolatedarea of data region 198 of flash memory 190 of FIG. 1, and audit log 620is stored in an isolated area of non-volatile memory such as an isolatedarea of non-volatile memory storage device 172 of FIG. 1. Becausenon-volatile memory is faster than flash memory, in one embodiment,audit event records are written first to the audit log stored innon-volatile memory (audit log 620 in this example) if non-volatilememory is available. Because I/O command decode module 140 prepares datafor I/O to storage devices and works directly with encryption engine 150to encrypt data as the data are written to storage devices, I/O moduleaudit subsystem 648 is coupled to the faster audit log 620 stored innon-volatile memory to reduce latency in processing I/O events. Becausemanageability engine audit subsystem 638 is not directly involved inI/O, manageability engine audit subsystem 638 writes audit event recordsto the slower audit log 610 stored in flash memory such as flash memory190.

When audit log 610 and/or audit log 620 reaches a threshold,manageability engine audit subsystem 638 may notify remote auditadministration service 640 to service the audit logs. In one embodiment,audit administration service 640 copies contents of audit logs 610 and620 to remote storage and resets the threshold value. Auditadministration service 640 does not interrupt operation of manageabilityengine audit subsystem 638 or I/O module audit subsystem 648, whichcontinue to write audit event records to their respective audit logs 610and 620 concurrently as auditable events are identified. When audit log620 approaches a threshold value, I/O module audit subsystem 648notifies manageability engine audit subsystem 638 via MECI 131 so thatmanageability engine audit subsystem 638 can send a request for serviceto audit administration service 640.

In one embodiment, manageability engine audit subsystem 638 works inconjunction with audit administration service 640 to manage all auditsubsystems active within the secure partition. Manageability engineaudit subsystem 638 may perform the functions of other audit subsystems,such as I/O module audit subsystem 648, when the other audit subsystemis overloaded and cannot process auditable events. Manageability engineaudit subsystem 638 may also service audit logs for other auditsubsystems. In one embodiment, manageability engine audit subsystem 638requires other audit subsystems to register. Registration is used tonotify manageability engine audit subsystem 638 that there is a localaudit log, such as audit log 620, being maintained by the other auditsubsystem. Registration may also be used to notify manageability auditsubsystem 638 whether discrete auditable events may be re-routed forprocessing, and/or whether servicing of audit logs is requested.

In one embodiment, the operation of manageability engine audit subsystem638 and I/O module audit subsystem 648 is controlled by enterprisedomain privileges using Kerberos tickets. In one embodiment, anauditable event being performed in a secure partition of a system isidentified, wherein the secure partition is isolated from a hostoperating system of the system. An audit event record is generated forthe auditable event and the audit event record is written to an auditlog that is isolated from the host operating system. In one embodiment,a plurality of auditable events is defined in an audit policy, the auditpolicy comprises instructions for servicing each auditable event of theplurality of auditable events, and identifying the auditable eventcomprises determining whether a detected event is one of the pluralityof auditable events defined in the audit policy.

The audit log may be a first audit log of a plurality of audit logs thatare accessible only from within the secure partition. Each audit log ofthe plurality of audit logs is isolated from the host operating system.In one embodiment, a determination is made whether the first audit logis available. The audit event record is sent to a first audit subsystemassociated with the first audit log if the first audit log is available,and the first audit subsystem performs writing the audit event record tothe first audit log. If the first audit log is not available, the auditevent record is sent to a second audit subsystem associated with asecond audit log of the plurality of audit logs, and the second auditsubsystem performs writing the audit event record to the second auditlog.

In one embodiment, the latency of write operations to the first auditlog is monitored. If the latency reaches a predetermined threshold,subsequent write operations are transferred to the second auditsubsystem so that subsequent audit event records for the subsequentwrite operations can be written to the second audit log. In anotherembodiment, if the latency reaches a predetermined threshold, a requestto service the first audit log is sent to the second audit subsystem.The second audit subsystem services the first audit log by moving auditevent records from the first audit log to another location, such as to athird audit log. In one embodiment, the second audit subsystem schedulesa remote management application to service the third audit log, theremote management application establishes a secure communication channelwith the secure partition, and the remote management applicationservices the third audit log via the secure communication channel.

In one embodiment, a request to service an audit log is received from asecure partition of a requesting system, wherein the secure partition isisolated from a host operating system of the requesting system, theaudit log contains an audit event record of an auditable event performedin the secure partition, and the audit log is isolated from the hostoperating system of the requesting system. A secure communicationchannel is established with the secure partition; and the audit log isserviced via the secure communication channel. Servicing the audit logmay include processing the auditable event in accordance with an auditpolicy.

FIG. 7 is a flowchart of a method to be performed upon detecting apotentially-auditable event occurring within a secure partition of asystem in accordance with one embodiment of the invention. Upon thedetection of an event occurring within a secure partition such aschipset/secure partition 120 at “Detect Event” step 702, controlproceeds to “Auditable Event?” decision point 704. At “Auditable Event?”decision point 704, either logic encoded in hardware and/or therespective audit subsystem (either manageability engine audit subsystem638 or I/O module audit subsystem 648) may check an audit policy todetermine whether the event is auditable. In one embodiment, an auditbit mask is used to activate different hardware and/or firmwarecomponents that are capable of detecting auditable events. Evaluation ofthe audit bit mask at “Auditable Event?” decision point 704 determineswhether the event is auditable.

At “Auditable Event?” decision point 704, if the event is auditable,control proceeds to “Generate Audit Event Record” step 706. An auditevent record is generated by either logic encoded in hardware and/or therespective audit subsystem (either manageability engine audit subsystem638 or I/O module audit subsystem 648). After generation of the auditevent record, control proceeds to “Is NVM Log Available?” decision point708. As discussed previously, if a non-volatile memory log is available,it is preferable to write the audit event record to non-volatile memoryto reduce latency associated with processing the event. At “Is NVM LogAvailable?” decision point 708, if an NVM log is available, controlproceeds to “Send Event Record to I/O Module Audit Subsystem” step 710.At “Send Event Record to I/O Module Audit Subsystem” step 710, the eventrecord is sent to I/O module audit subsystem 648.

From “Send Event Record to I/O Module Audit Subsystem” step 710, controlproceeds to “Threshold Reached?” decision point 712. Examples of athreshold being reached are when I/O Module utilization falls belownormal levels and/or the audit log becomes full. When a threshold isreached, control proceeds to “Send Threshold Status to ManageabilityEngine Audit Subsystem” step 718. For example, when I/O moduleutilization falls below the threshold level, audit activity may need tobe offloaded to manageability engine audit subsystem 638 and/or auditlog 620 may need to be serviced. When “Send Threshold Status toManageability Engine Audit Subsystem” step 718 is executed,manageability engine audit subsystem 638 takes the appropriate action tomanage reaching the threshold in accordance with the audit policy. Forexample, manageability engine audit subsystem 638 may schedule auditadministration service 640 to service the log and/or copy the log thathas reached a threshold to other archive storage. From “Send ThresholdStatus to Manageability Engine Audit Subsystem” step 718, controlproceeds to “Write Event Record to Audit Log” step 715, where the auditevent record that caused the threshold to be reached is written to a logby manageability engine audit subsystem 638.

From “Threshold Reached?” decision point 712, if no threshold has beenreached, control proceeds to “Write Event Record to Audit Log” step 715,where the respective audit subsystem writes the audit event record toits respective log. Control then proceeds to “Perform Event” step 714,where the event is performed and processing the auditable event iscomplete.

At “Is NVM Log Available?” decision point 708, if an NVM log is notavailable, control proceeds to “Sent Event Record to ManageabilityEngine Audit Subsystem” step 716. The audit event record is sent tomanageability engine audit subsystem 638. Manageability engine auditsubsystem 638 then writes the event record to audit log 610 in “WriteEvent Record to Audit Log” step 715. Control proceeds to “Perform Event”step 714, where the event is performed and processing the auditableevent is complete.

At “Auditable Event?” decision point 704, if the event is not auditable,control proceeds to “Perform Event” step 714. The event is performed andprocessing of the event is complete.

Processing of auditable events can be performed by logic encoded inhardware and/or by firmware. Initialization of chipset/secure partition120 components, such as manageability engine (ME) 130, I/O commanddecode module 140, and encryption engine 150 are auditable events thatmay be encoded into the hardware for those respective components and/orincluded in firmware for those respective components. Similarly,hardware and/or firmware for controllers and interfaces, such as HECI111 b, VECI 111 c, network controller 160, USB controller 175, I/Ocontroller 170 may include logic to process auditable events.

Audit event processing can be performed within manageability engine (ME)130 upon initial configuration as well as during operation of componentsof manageability engine (ME) 130, such as during operation ofsecurity/key management firmware 237 of FIG. 2. For example, auditevents may be triggered when security/key management firmware 237 writesa device encryption key (DEK) into a corresponding register ofencryption engine 150 when a storage device is to be encrypted orremoves the DEK from the corresponding register of encryption engine 150when encryption is disabled.

Audit event processing may also be performed when data are transferredin cleartext form from I/O controller 170 to encryption engine 150 (fora write operation) and when data are returned by encryption engine 150in cipher-text form. Auditing events occurring via the channel betweenI/O controller 170 and encryption engine 150 provides proof that dataare being encrypted, although the audit policy may limit auditing theseevents to periodic compliance testing.

Audit event processing may be performed at manageability enginecontroller interface (MECI) 131 because coordination between auditsubsystems may be communicated via MECI 131. Initial configuration ofI/O command decode module 140 is also performed via MECI 131 and willgenerate auditable events.

Audit event processing may be generated by communication from processor110 via interfaces HECI 111 b and VECI 111 c. For example, ATA securitycommands that pertain to the locking state of a device produce auditableevents, as well as commands that propagate via these interfaces to I/Ocontroller 170 or USB controller 175. Furthermore, HECI commandspertaining to user authentication, encryption, security, key management,and status are auditable events. Commands used to initialize controllerssuch as I/O controller 170, USB controller 175, and network controller160 are also auditable events. Audit log storage and configurationcommands are also auditable, as are audit subsystem communication withremote audit administration service 640 of FIG. 6. Attachment of adevice to platform 100 via USB controller 175 and/or I/O controller 170is an auditable event.

By configuring particular events to be auditable or not in an auditpolicy, the audit system can be fine-tuned to balance performance,storage capacity, and security. By managing audit subsystems via aremote management console and audit administration service via a securecommunication channel, integrity of audit information can be protected.

FIG. 8 shows a virtual machine environment for implementing a securepartition for managing actions such as protecting devices usingencryption, user identity authentication, and password protectionschemes in accordance with one embodiment of the invention. If platform800 is virtualized, it may include only a single processor but a virtualmachine monitor (“VMM 830”) on the host may present multipleabstractions and/or views of the host, such that the underlying hardwareof the host appears as one or more independently operating virtualmachines (“VMs”). VMM 830 may be implemented in software (e.g., as astandalone program and/or a component of a host operating system),hardware, firmware and/or any combination thereof. VMM 830 managesallocation of resources on the host and performs context switching asnecessary to cycle between various VMs according to a round-robin orother predetermined scheme. It will be readily apparent to those ofordinary skill in the art that although only one processor isillustrated (“Processor 805”), embodiments of the present invention arenot so limited and multiple processors may also be utilized within avirtualized environment.

Although only two VM partitions are illustrated (“VM 810” and “VM 820”,hereafter referred to collectively as “VMs”), these VMs are merelyillustrative and additional virtual machines may be added to the host.VM 810 and VM 820 may function as self-contained platforms respectively,running their own “guest operating systems” (i.e., operating systemshosted by VMM 830, illustrated as “Guest OS 811” and “Guest OS 821” andhereafter referred to collectively as “Guest OS”) and other software(illustrated as “Guest Software 812” and “Guest Software 822” andhereafter referred to collectively as “Guest Software”).

Each Guest OS and/or Guest Software operates as if it were running on adedicated computer rather than a virtual machine. That is, each Guest OSand/or Guest Software may expect to control various events and haveaccess to hardware resources on platform 800. Within each VM, the GuestOS and/or Guest Software may behave as if they were, in effect, runningon platform 800's physical hardware (“Host Hardware 840”, which mayinclude a network controller 860).

It will be readily apparent to those of ordinary skill in the art that aphysical hardware partition with a dedicated processor such asmanageability engine (ME) 130 of FIG. 1 may provide a higher level ofsecurity than a virtualized partition (as illustrated in FIG. 8), butembodiments of the invention may be practiced in either environmentand/or a combination of these environments to provide varying levels ofsecurity. It will also be readily apparent to those of ordinary skill inthe art that an ME, AMT or PRL platform may be implemented within avirtualized environment. For example, VM 820 may be dedicated as an MEpartition on a host while VM 810 runs typical applications on the host.In this scenario, the host may or may not include multiple processors.If the host does include two processors, for example, VM 820 may beassigned the other processor while VM 810 (and other VMs on the host)may share the resources of processor 805. On the other hand, if the hostincludes only a single processor, the processor may serve both the VMs,but VM 820 may still be isolated from the other VMs on the host with thecooperation of VMM 830. For the purposes of simplicity, embodiments ofthe invention are described in a manageability engine (ME) environment,but embodiments of the invention are not so limited. Instead, anyreference to manageability engine, ME, a “partition”, “a securepartition”, a “security partition” and/or a “management partition” shallinclude any physical and/or virtual partition (as described above).

Upon start-up or when a new device is hot-plugged into the platform, VMM830 assigns the device to a VM 810 or 820. To perform auditing withinchipset/secure partition 120 in a virtualized environment such as thatdescribed in FIG. 8, VMM 830 manages an audit mask profile for each ofVMs 810 and 820. When a device is assigned to either VM 810 or 820, therespective audit mask profile for the VM is associated with thechipset/secure partition 120. Each time the VM audit mask profileassociated with chipset/secure partition 120 changes, VMM 830 generatesan audit event record. In this way, the VM 810 or 820 that initiates anauditable event is represented in the audit event records. For example,the VM 810 or 820 that issues storage I/O commands to the device isidentified in the audit event records.

If a device is hot-plugged into the platform, the VM 810 or 820 thatreceived the device assignment is identified in the audit event record.When a hot-plug event is detected, I/O command decode module 140 mayneed to determine whether the VM 810 or 820 currently associated withchipset/secure partition 120 is authorized to receive the deviceassignment. Until the device is assigned and the correct audit maskprofile to be assigned to chipset/secure partition 120 can bedetermined, an internal audit mask profile may be used to audit eventsafter the hot-plug event until device assignment occurs.

VMM 830 may identify the currently active VM audit mask profile tochipset/secure partition by writing the currently active audit maskprofile to flash memory 190. Flash memory 190 is also used to maintainuser account metadata associated with each VM. When a storage device isto be unlocked using either a device password or a device encryptionkey, an additional check can be performed to ensure that the useraccount metadata in flash memory 190 corresponds to the VM to which thedevice was assigned.

VMM 830 ensures that transient VM environments do not result inunauthorized assignment of drives. In one embodiment, VMM 830 generatesa GUID (globally unique ID) for each VM 810 and 820. The GUID is used topartition metadata in flash memory 190.

Embodiments of the mechanisms disclosed herein may be implemented inhardware, software, firmware, or a combination of such implementationapproaches. Embodiments of the invention may be implemented as computerprograms executing on programmable systems comprising at least oneprocessor, a data storage system (including volatile and non-volatilememory and/or storage elements), at least one input device, and at leastone output device.

Program code may be applied to input data to perform the functionsdescribed herein and generate output information. Embodiments of theinvention also include machine-accessible media containing instructionsfor performing the operations of the invention or containing designdata, such as HDL, which defines structures, circuits, apparatuses,processors and/or system features described herein. Such embodiments mayalso be referred to as program products.

Such machine-accessible storage media may include, without limitation,tangible arrangements of particles manufactured or formed by a machineor device, including storage media such as hard disks, any other type ofdisk including floppy disks, optical disks, compact disk read-onlymemories (CD-ROMs), compact disk rewritable's (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash programmable memories(FLASH), electrically erasable programmable read-only memories(EEPROMs), magnetic or optical cards, or any other type of mediasuitable for storing electronic instructions.

The output information may be applied to one or more output devices, inknown fashion. For purposes of this application, a processing systemincludes any system that has a processor, such as, for example; adigital signal processor (DSP), a microcontroller, an applicationspecific integrated circuit (ASIC), or a microprocessor.

The programs may be implemented in a high level procedural or objectoriented programming language to communicate with a processing system.The programs may also be implemented in assembly or machine language, ifdesired. In fact, the mechanisms described herein are not limited inscope to any particular programming language. In any case, the languagemay be a compiled or interpreted language.

Presented herein are embodiments of methods and systems for managementof devices protected by encryption, user authentication, and passwordprotection schemes. While particular embodiments of the presentinvention have been shown and described, it will be obvious to thoseskilled in the art that numerous changes, variations and modificationscan be made without departing from the scope of the appended claims.Accordingly, one of skill in the art will recognize that changes andmodifications can be made without departing from the present inventionin its broader aspects. The appended claims are to encompass withintheir scope all such changes, variations, and modifications that fallwithin the true scope and spirit of the present invention.

1. A computer-implemented method comprising: receiving a request tounlock an encrypted device coupled to a system, wherein the request isreceived by a secure partition of the system via a secure communicationchannel established between a trusted remote console and the securepartition, and the secure partition is isolated from a host operatingsystem of the system; and the secure partition unlocking the encrypteddevice in response to the request without involvement of the hostoperating system.
 2. The method of claim 1, further comprising:receiving a token from the trusted remote console by the securepartition; and using the token to unwrap a key used to encrypt blocks ofthe encrypted device.
 3. The method of claim 2, further comprising:obtaining the key from a secure storage area of the encrypted device,wherein the secure storage area is hidden from the host operatingsystem.
 4. The method of claim 1, further comprising: confirming thatthe request originated with the trusted remote console prior tounlocking the encrypted device.
 5. The method of claim 1, furthercomprising: performing a management operation after the encrypted deviceis unlocked, wherein the request further specifies the managementoperation to be performed; and booting the host operating system afterthe management operation is performed.
 6. The method of claim 1, whereinunlocking the encrypted device is performed when the host operatingsystem of the system is malfunctioning.
 7. The method of claim 1,wherein unlocking the encrypted device is performed without involvementof a user of the system.
 8. The method of claim 1, wherein the requestcomprises a password for the encrypted device; and unlocking theencrypted device comprises using the password to unlock the encrypteddevice.
 9. An apparatus comprising: at least one processor; a securepartition isolated from a host operating system executing on theprocessor; and a memory comprising instructions for a device managerexecuting in the secure partition to perform the following: receiving arequest to unlock an encrypted device coupled to the apparatus, whereinthe request is received by the secure partition via a securecommunication channel established between a trusted remote console andthe secure partition, and the secure partition is isolated from the hostoperating system; and unlocking the encrypted device in response to therequest without involvement of the host operating system.
 10. A computerprogram product comprising: a computer-readable storage medium; andinstructions in the computer-readable storage medium, wherein theinstructions, when executed in a secure partition of a processingsystem, cause the secure partition to perform operations comprising:receiving a request to unlock an encrypted device coupled to theprocessing system, wherein the request is received by the securepartition via a secure communication channel established between atrusted remote console and the secure partition, and the securepartition is isolated from a host operating system of the processingsystem; and unlocking the encrypted device in response to the requestwithout involvement of the host operating system.
 11. Acomputer-implemented method comprising: establishing a securecommunication channel between a trusted remote console and a securepartition of a system, wherein the secure partition is isolated from ahost operating system of the system; and sending a request to unlock anencrypted device coupled to the system, wherein the request is sent viathe secure communication channel to the secure partition, and whereinthe encrypted device is unlocked by the secure partition withoutinvolvement of a host operating system of the system.
 12. The method ofclaim 11, further comprising: providing a token from the trusted remoteconsole to the secure partition in the request, wherein the securepartition uses the token to unwrap a key used to decrypt blocks storedon the encrypted device.
 13. The method of claim 11, further comprising:providing a password for the encrypted device in the request, whereinthe secure partition uses the password to unlock the encrypted device.14. The method of claim 11, further comprising: specifying in therequest a management operation to be performed after the encrypteddevice is unlocked, wherein the secure partition performs the managementoperation after the encrypted device is unlocked.
 15. Acomputer-implemented method comprising: authenticating first credentialsof a user of a system before access is allowed to any device of aplurality of devices attached to the system; intercepting an eventindicating attachment of a new device to the system, wherein theintercepting is performed by a secure partition of the system, and thesecure partition is isolated from a host operating system of the system;requesting second credentials to access the new device, wherein thesecond credentials are requested without booting the system;authenticating the second credentials; enabling access to the new deviceafter authenticating the second credentials; and delivering a hot plugevent for the new device to the host operating system.
 16. The method ofclaim 15, wherein requesting the second credentials to access the newdevice comprises using trusted path connections to a display device todisplay a request for the second credentials and a user input device toreceive the second credentials.
 17. The method of claim 15, whereinenabling access to the new device comprises using a native command forthe device to enable decryption of the new device.
 18. The method ofclaim 15, wherein the second credentials comprise a password for the newdevice; and enabling access to the new device comprises using thepassword to unlock the new device.
 19. The method of claim 15, whereinthe second credentials comprise a user identifier; and enabling accessto the new device comprises providing the user identifier to a trustedthird party and enabling access to the new device if the trusted thirdparty authenticates the user identifier.
 20. An apparatus comprising: atleast one processor; a secure partition isolated from a host operatingsystem executing on the processor; and a memory comprising instructionsfor firmware executing in the secure partition to perform the following:authenticating first credentials of a user of a system before access isallowed to any device of a plurality of devices attached to the system;intercepting an event indicating attachment of a new device to thesystem, wherein the intercepting is performed by the secure partition;requesting second credentials to access the new device, wherein thesecond credentials are requested without booting the system;authenticating the second credentials; enabling access to the new deviceafter authenticating the second credentials; and delivering a hot plugevent for the new device to the host operating system.
 21. A computerprogram product comprising: a computer-readable storage medium; andinstructions in the computer-readable storage medium, wherein theinstructions, when executed in a secure partition of a processingsystem, cause the secure partition to perform operations comprising:authenticating first credentials of a user of a system before access isallowed to any device of a plurality of devices attached to the system;intercepting an event indicating attachment of a new device to thesystem, wherein the intercepting is performed by the secure partition,and the secure partition is isolated from a host operating system of thesystem; requesting second credentials to access the new device, whereinthe second credentials are requested without booting the system;authenticating the second credentials; enabling access to the new deviceafter authenticating the second credentials; and delivering a hot plugevent for the new device to the host operating system.
 22. Acomputer-implemented method comprising: identifying an auditable eventbeing performed in a secure partition of a system, wherein the securepartition is isolated from a host operating system of the system;generating an audit event record for the auditable event; and writingthe audit event record to an audit log, wherein the audit log isisolated from the host operating system.
 23. The method of claim 22wherein the audit log is a first audit log of a plurality of audit logs,the plurality of audit logs is accessible only from within the securepartition, and each audit log of the plurality of audit logs is isolatedfrom the host operating system; and the method further comprises:determining whether the first audit log is available; sending the auditevent record to a first audit subsystem associated with the first auditlog if the first audit log is available, wherein the first auditsubsystem performs writing the audit event record to the first auditlog; and sending the audit event record to a second audit subsystemassociated with a second audit log of the plurality of audit logs if thefirst audit log is not available, wherein the second audit subsystemperforms writing the audit event record to the second audit log.
 24. Acomputer-implemented method comprising: receiving a request to servicean audit log from a secure partition of a requesting system, wherein thesecure partition is isolated from a host operating system of therequesting system, the audit log contains an audit event record of anauditable event performed in the secure partition, and the audit log isisolated from the host operating system of the requesting system;establishing a secure communication channel with the secure partition;and servicing the audit log via the secure communication channel.